Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-houttuin-mailservers-02.txt < prev next >

Wrap

Text File | 1993-09-28 | 52.8 KB | 1,476 lines

INTERNET-DRAFT Jeroen Houttuin Mail Applicability Design Team RARE Secretariat rev. 4.0 Sept. 1993 Header Behaviour of Mail Based Servers (H-bombs) Abstract This document defines recommendations to be implemented in mail based servers in the Internet and GO-MHS e-mail communities. The requirements only affect the basic behaviour of servers, i.e. it mainly deals with how header fields are handled. Although there is also a clear need for recommendations in the field of end user requirements, such as command syntaxes for archive servers, automatic distribution list subscription, etc., such issues are considered more suitable to be dealt with in a separate document. It is highly desirable that other e-mail networks connected to the Internet also implement these recommendations. Discussion group This document has been presented and discussed in several groups since late 1992: the RARE Working Group on Mail and Messaging (WG- MSG), The GO-MHS managers group, the IETF X400ops Working Group and the IFIP Mail Management Group. It is now being finalised by the IETF solicited "Mail Applicability Statement" design team. Depending on the nature of your comments, please send them to one of the following addresses: The main discussion group: wg-msg@rare.nl The design team: mail-as@infoods.unu.edu The author: houttuin@rare.nl Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Houttuin Expires March 1994 [Page 1] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 Contents [approximate page numbers......] 1. Introduction 1 2. Approach 2 3. Protocols 3 4. How to use this document 4 5. Definitions 4 5.1. Mail Based Server 4 5.2. Dedicated and non-dedicated MBSs 5 5.3. MBS administrator 5 5.4. Input- and output messages 5 5.5. MBS Submit Permission 6 5.6. Message originator (necessary?) 6 6. Mail based server types 6 6.1. Repliers 6 6.1.1. Echo server 7 6.1.2. Mailer demon 7 6.1.3. Command server 7 6.1.4. Auto-replier 8 6.2. Forwarders 8 6.2.1. Distribution List 8 6.2.2. Redirector 8 6.2.2. Auto-forwarder 9 7. Rules 9 7.1. Attribute/header restrictions (AR) 9 7.2. Attribute/header values (AV) 12 7.3. Attribute/header conservation (AC) 14 7.4. Addresses (AD) 15 7.5. Body (B) 16 7.6. Exceptions (E) 17 7.7. Logging (L) 18 7.8. Implementation options (I) 18 8. Summary table 19 8. Reference implementations 21 9. Further work 21 10. Acknowledgements 21 11. Bibliography 22 12. Abbreviations 23 13. Author's Address 23 1. Introduction Electronic mail systems are increasingly being used as a basis for so called Mail Based Servers (MBSs), such as echo servers, distribution lists, file distribution servers, etc. MBSs are used for a number of purposes: Houttuin Expires March 1994 [Page 2] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 - Enhancing the Message Handling Environment. Examples of such usage are distribution lists (DLs), for group communication, and e-mail servers, for file and information retrieval. - Monitoring the status of the MHS. Examples of this usage are echo servers and forced (non-)delivery messages (E.g. the so- called nosuchuser test). Since MBSs deal with automatically receiving, forwarding and replying to messages, which may themselves have been generated by automated processes, strong requirements are needed on the one hand to minimise human effort to manage such servers, and on the other hand to make the behaviour of mail based servers deterministic enough to build reliable tools upon them. A classic example of what can go wrong is when a mailing list contains an invalid address. The remote mailer generates a non- delivery message and sends it to the originator of the original message, which, under some circumstances, could be the list itself, which then distributes the non-delivery message to the list, and thus also to the erroneous address, etc. etc. Following strict recommendations on how mailing lists should deal with message header fields can avoid such looping-endangered situations. A more complicated example of the need for strong requirements for MBSs is the following: suppose a distributed tool will check the connectivity of mailers by sending a message to an echo-server. The connectivity tool could request the echo to be sent to a remote component of the tool instead of to itself. If for some reason the address of that other component cannot be routed to, an automatically generated non-delivery message could be sent back to the echo server, which results in an echo loop. As far as appropriate, the recommendations defined in this document will be aligned with comparable rules that either have already been used for a long time (X.400(84) Status Reports; distribution lists in the Internet; Internet host requirements), or are already defined in other documents (X.400(88) DLs; Internet host requirements). 2. Approach If all MBSs would agree to implement a common set of behaviour rules, this set could be fairly small. In practice however, there are some reasons why such a 'minimum approach' will not work: - The most obvious reason is that one cannot realistically expect all networks and software developers to implement one common strict set of rules. In different mail communities, different MBS conventions have already been used for a long time. Some of Houttuin Expires March 1994 [Page 3] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 these conventions can be unacceptable for other communities to implement. - MBSs can be built upon different underlying protocols. For instance, it is almost impossible to have a small set of rules that will prevent problems between any combination of MBSs, e.g. between a near RFC 822 MBS running over NJE and a P1 based MBS. More problems can be expected because header fields are crucial for the properly functioning of MBSs, and protocol gateways will not always map header fields bijectively. - Not all MBSs are controlled by software developers or network operators. Any user can write a simple program that will have the functionality of an MBS. Because the 'minimum approach' is not feasible, this document recommends the 'unilateral safety approach'. The idea is that any MBS that implements the complete set of recommendations will be safe from harm, regardless of what other 'dumb' MBSs it is interacting with. This results in quite a large number of recommendations, of which not every single one is strictly necessary to prevent problems, but none of them will 'hurt' the functioning of an MBS. As for the programming overhead caused by this document, there is at least one example of an echo server (Echoput) that implements all recommendations proposed in this document; the size of the (perl) code fits on two pages. In addition to the rules that should protect against loops and explosions, there are also some recommendations reflecting common sense. For instance, if a user sends a message flagged 'urgent' to a mail based file server, he would not only expect his request message to be handled with extra priority, but also the reply message. 3. Protocols For many MBSs, it is not known beforehand in which protocol world they are located. In order to come to a consistent MBS behaviour regardless of this location, this document describes recommendations for both RFC mail and X.400 MBSs. Note that a one hundred percent transparency cannot be reached, because there exists no one-to-one mapping between all RFC mail and X.400 service elements. Apart from that, applying RFC 1327 mapping to a service element from X.400 may clash with a host requirement for the RFC mail service element. In this case, there will have to be functionally different recommendations depending in which protocol world the MBS is located. More concrete; depending on the implementation of the MBS, different recommendations must be used. E.g. a P1 MBS cannot follow all recommendations for RFC 822 based MBSs and vice versa. Houttuin Expires March 1994 [Page 4] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 4. How to use this document For the reader's convenience, the rules for different MBS implementations are explicitly stated in the appropriate terminologies. The rules are labelled as follows: #RFC# Applies to RFC 822 on top of RFC 821 (SMTP) based MBSs #821# Applies to RFC 821 based MBSs #822# Applies to RFC 822 based MBSs #1327# Rules visible in RFC 822 message due to RFC 1327 mappings #400# Applies to X.400 (both 84 and 88) based MBSs #84# Applies to X.400(84) based MBSs #88# Applies to X.400(88) based MBSs #P1# Applies to P1 based MBSs #P2# Applies to P2 based MBSs #P3# Applies to P3 based MBSs Terms such as 'P1 based' and 'RFC 822 on top of RFC 821' may need some further explanation. P1 based MBSs operate as MTA functions (e.g. they process envelope information only), whereas P2 and RFC 822 MBSs assume UA functionality (e.g. they process mail headers). P3 based MBSs use the MTS, and may additionally interpret the contents of messages (if this message is P2, we're back at the definition of a P2 MBS). The distinction between P1 and P3 based MBSs is mostly conceptual. In the Internet, this distinction cannot even be made. Note that some the RFC 822 recommendations listed here deal with non- standard headers as described in RFC 1327. This is needed to provide protection across gateways. Implementors can use the summary table in chapter 8, and check all '+' entries for the type of MBS and protocol suite they want to implement. 5. Definitions 5.1. Mail Based Server An MBS is a process that automatically generates one or more messages (the output messages) as a result of receiving a message (the input message). An MBS can be modelled and/or implemented in one of the following ways: - #RFC#: As a process sitting directly on top of SMTP. This is called an 821 MBS. If, in addition, the MBS is RFC 822 based, it is called an 822 MBS. Houttuin Expires March 1994 [Page 5] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 - #400#: within the MTS, in which case it can be considered an enhancement of the X.400 message dispatcher. This is called a P1 MBS. - #400#: as an MTS service user, in which case it can be considered an automated User Agent (UA). Per default, this is called a P3 MBS. If, in addition, the MBS is P2 based, it is called a P2 MBS. P7 based MBSs are not considered in this document. The number of output messages and its contents depend on the kind of server and on the contents of the input message. Our definition rules out a number of mail based applications: - A proces that is in someway triggered by an input message, but does not necessarily generate an output message. Think of process control applications. - Applications that need more than one input message to trigger the generation of an output message. For such work flow management types of applications, it is already nearly impossible to define globally applicable rules for how the recipient of the output message(s) should be determined. It is however possible to treat an MBS as a special subclass of such systems, namely where the number of input messages is exactly one. Hopefully this document can be used as a starting point for later studies on the behaviour of more complex systems. - Applications that do not completely automatically generate output messages. This rules out mail based applications that need (human) intervention, such as moderated distribution lists. 5.2. Dedicated and non-dedicated MBSs A dedicated MBS is an MBS that is meant to be used as an MBS only. Examples of non-dedicated MBSs are temporarily auto-forwarding user agents (UAs), and UAs that automatically send back vacation notes (auto-repliers). Although software developers are encouraged to implement such features as if it concerned a dedicated MBS, there are some differences between the two types. For instance, it is not realistic to assume a separate MBS administrator (see below) for every stand-alone UA. Also, non-dedicated MBSs often have a more limited life time, which results in some extra recommendations. 5.3. MBS administrator For every dedicated MBS, there exists an MBS administrator who is responsible for managing the MBS. This person, or group of persons, Houttuin Expires March 1994 [Page 6] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 must be informed about possible malbehaviour of the server, such as loops, unreachable addresses on mailing lists and rejected messages. Other possible roles related to the management of an MBS are: Owner Has the responsibility for the existence of the MBS. Operator Operates the hard- and software. Moderator Moderates a mailing list. Other Many other roles can be thought of. Note that in practice, most of these roles will be played by one and the same person. The only role that is important in this document is that of the MBS adminstrator. 5.4. Input- and output messages An input message is a message that triggers the generation of one or more output messages by an MBS. An output message is a message that is being generated by an MBS as a result of receiving an input message. If an MBS encounters an error (as defined in the recommendations below), one exception output message is generated instead of a regular output message. This message is sent to the MBS administrator. If a non-dedicated MBS does not have an MBS administrator, the exception output message may either be sent to the originator (see below) of the input message. If by sending the exception message to the originator of the input message, the MBS would encounter a situation that would normally lead to an exception situation (e.g. the originator of the input message is known to be an automatic replier), it does not generate an output message at all. 5.5. MBS Submit Permission Associated with an MBS is a number of addresses that are allowed to use the MBS (I.e. have the MBS send output messages). Implementation of MBS Submit Permission is considered a local matter. The main implementation options are: - Implicit: Only those addresses explicitly listed are not allowed to send messages to the MBS. - Explicit: Only those addresses explicitly listed are allowed to send messages to the MBS. Houttuin Expires March 1994 [Page 7] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 5.6. Message originator (necessary?) #RFC# The originator of an input message is defined as the MAIL FROM: address. This is the definition of 'originator' and MUST be used whenever possible. For RFC 822 based MBSs that, for some reason, cannot access envelope attributes, the originator of an input message is defined as the RFC 822 Return-Path: . If this header is not available either, the originator of an input message is defined as the RFC 822 Sender: , and in the absence of that header, the RFC 822 From: . #400# The originator of an input message is defined as the P1 or P3 originator. For P2 based MBSs that cannot access P3 attributes, the originator of an input message is defined as the P2.originator, or if this attribute is not present, the P2.authorizingUsers. 6. Mail based server types This chapter defines the different types of MBSs. Two main types are identified: repliers and forwarders. 6.1. Repliers Intuitively speaking, a replier is an MBS that will send an output message to the originator of the input message. There are also exceptions to this rule, such as replying to a Reply-To: field. More formally speaking, a replier is characterised by the fact that the recipient of the output message is uniquely defined in (the heading of) the input message. The different types of repliers can be classified by the number and content of the output message. Most existing repliers operate at UA level. 6.1.1. Echo server An echo server is a dedicated replier that will generate exactly one output message, containing at least the input message. 6.1.2. Mailer demon This document does not consider the behaviour of X.400 delivery reports and notifications, which is assumed to be well defined in X.400 already. RFC 822 mailers and RFC 1327 gateways however can generate a message explaining the (NON-)Delivery of an input message, a so-called Delivery Message (DM). In this case the mailer/gateway is acting as an MBS. Houttuin Expires March 1994 [Page 8] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 For mailer demons, the behaviour is well defined in other documents, such as RFC 821 and RFC 1123. The MBS administrator is the administrator of the mailer/gateway. Ideally a gateway should behave as a normal mailer when a message is not deliverable. In practice however, the following may occur. The gateway accepts from the Internet mail side a message in which it recognises an RFC 822 encoded X.400 address. The gateway performs the gatewaying and then discovers that the X.400 message is not deliverable. The gateway has two options in this case. Either it creates an X.400 non-delivery report and gateways it back to the Internet mail world, or it immediately generates an RFC non-delivery message. Internet mailer demons conceptually operate at MTA or MTS level, although, as usual with Internet mailers, they may interpret and under circumstances even add UA level information. This especially holds for mail protocol gateways. 6.1.3. Command server The contents of an output message generated by a command server depend on commands that were included in the input message. Concrete examples are file servers, e-mail archie servers, DL-registration servers and address conversion servers. Although it is beyond the scope of this document to define detailed requirements for the command syntax used by command servers, some general recommendations concerning header fields are described here. Note that an echo server can be regarded as a special type of command server, namely one that ignores all commands. 6.1.4. Auto-replier Some UAs have an auto-reply feature that will temporarily and/or conditionally turn the UA into an MBS. Thus an auto-replier is a non- dedicated replier. The content of the output message is often a note such as 'I am on holidays.' An auto-replier has a certain lifetime, which is defined as the time span between switching the auto-replier on and back off again. 6.2. Forwarders A forwarder is an MBS that will send its output messages to a list of recipients. These recipients are independent of (the heading of) the input message. Houttuin Expires March 1994 [Page 9] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 6.2.1. Distribution List Upon receiving an input message, a DL will generate output messages to a list of DL members, which is managed by the DL administrator. At the moment many vendor-specific implementations of DLs exist. Some of these are nothing more than local multi-recipient aliases, others use local directories for DL expansion. This document defines the requirements for DLs as well as implementation options. Although a moderateddistribution list does not fit into our definition of an MBS, a moderated DL ican be modelled as a normal DL with an extra filtering of the input messages. In case of message rejection by the moderator, it is considered good manners for the moderator to follow, in a rejection message, the header recommendations that this document describes for mailer demons. If the message is accepted for distribution, the moderator should ideally transparently pass through all MBS control information (headers and envelope) to the actual DL. The moderation process itself (editing of the contents) is considered a local matter. 6.2.2. Redirector Some MTAs have a redirection feature that will temporarily and/or conditionally turn the MTA into an MBS. Thus a redirector can be considered a non-dedicated forwarder. Upon receiving an input message, an auto-forwarder will submit an output message to a locally defined (list of) address(es), which is managed..... Although a redirector often has a certain lifetime, like an auto- replier, this has no implications for the requirements for auto- forwarders. 6.2.2. Auto-forwarder Some UAs have an auto-forward feature that will temporarily and/or conditionally turn the UA into an MBS. Thus an auto-forwarder can be considered a non-dedicated forwarder. Upon receiving an input message, an auto-forwarder will submit an output message to a locally defined (list of) address(es), which is managed by the owner of the UA. Although an auto-forwarder often has a certain lifetime, like an auto- replier, this has no implications for the requirements for auto- forwarders. The main difference with a redirector is that an auto-forwarder conceptually operates at UA level. In almost all cases redirection is to be preferred over auto-forwarding. Houttuin Expires March 1994 [Page 10] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 7. Rules Depending on the implementation, MBSs follow the requirements defined in RFC 822, RFC 821, RFC 1123, X.411, X.420 and X.435 as a minimum. This chapter describes additional requirements in terms of RFC 821, RFC 822, P1, P3, and P2 for the MBS types distinguished above. 7.1. Attribute/header restrictions (AR) AR1 Avoiding replies to replies DISCUSSION: If an MBS would request some form of reply or report for an output message, other MBSs might as a result automatically send a message, report or (non)delivery message back to the MBS, which must be avoided at all cost, or to the MBS administrator, which is highly undesirable. This leads to rules AR1.1-AR1.5. ORIGIN: This memo AFFECTED: Repliers AR1.1 RULE: The following attribute is not used in the output message: #P2# Recipient.replyRequest I.e. the value of this argument defaults to FALSE AR1.2 RULE: The following attribute is not used in the output message: #1327# Reply-By: #84#P2# replyBy #88#P2# reply-time AR1.3 RULE: The following attribute is not used in the output message: #84#P2# expiryDate #88#P2# Expiry Time #1327# Expiry-Date: Houttuin Expires March 1994 [Page 11] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 AR1.4 RULE: The following attribute is not used in the output message: #88#P1#P3# Proof-of-delivery-request I.e. the value of this argument defaults to proof-of-delivery-not- requested. AR1.5 RULE: The following attribute is not used in the output message: #84#P2# replyToUsers #88#P2# reply-recipients #822# Reply-To: AR2 DISCUSSION: There is no need for a user to automatically forward his incoming messages through another MBS, which would introduce one superfluous hop. The only case where this might make sense is if the mail would be autoforwarded to support old addresses. But even in this case, auto redirection is preferred. Note that non-auto- forwarded messages can only be unambiguously identified in P2, Internet mail has no standard headers for this purpose. RFC 1327 gateways map this attribute to a new RFC 822 header "Auto- Forwarded:". In the presence of this header, RFC based MBSs can safely assume that the message was indeed auto-forwarded. ORIGIN: This memo. AFFECTED: All MBSs except distribution lists. RULE: #P2# An auto-forwarded message is not valid as an input message. The result is the generation of an exception output message. AR3 DISCUSSION: A user of a UA level replier may request the output message to be sent to another address. AFFECTED: UA level repliers, mailer demons. ORIGIN: Common practice, RFC 821, RFC 822, RFC 1123, X.400. RULE: The output message is sent to the originator of the input message. If the input message contains the following field, a UA- level replier sends the output message to the address in that field instead. If this field contains more than one address, an output Houttuin Expires March 1994 [Page 12] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 message is sent to at least the first address of this field. (Sending to the others is not recommended.) #84#P2# replyToUsers #88#P2# reply-recipients #822# Reply-To: AR4 DISCUSSION: A user who receives mail from an MBS, wihtout having ordered this information himself, has the right to know who was responsible for having messages sent to his mailbox. The semantics of both RFC 822 and X.400 header fields allow to specify that a message was sent from a certain address, but was authorised by someone else. This matches the semantics needed here. Another reason for using header fields for carrying this information is that the addresses will still be readable for the end-user after the message has crossed a protocol gateway. ORIGIN: This document, RFC 822, RFC 1327, X.400. AFFECTED: command and echo servers. RULE: #822# If the output message is not sent to the originator of the input message, its From: field field contains the addresses of the From: and the Sender: fields of the input message. In this case the Sender: field of the output message contains the address of the MBS administrator. RULE: #P2# If the output message is not sent to the P2.originator of the input message, its P2.authorizingUsers field contains the addresses of the P2.originator and the P2.authorizingUsers of the input message. AR5 RULE: An exception output message is generated if the input message contains either of the following attributes: #822# In-Reply-To: References: #P2# In-Reply-To crossReferences Houttuin Expires March 1994 [Page 13] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 7.2. Attribute/header values (AV) AV1 RULE: If the following field is used in the output message, it does not contain the address of the MBS. #84#P2# replyToUsers #88#P2# reply-recipients #822# Reply-To: AV2.1 DISCUSSION: Repliers should not send output messages to addresses which are likely to be repliers themselves, to avoid loops. RULE: Repliers do not send output messages to addresses with the following values in the local address designator (S, CN, localpart): autoanswer echo listserv mailerdaemon mirror netserv server These values must be matched in any combination of upper case and lower case. Instead, an exception output message is generated. This list is subject to change; an up-to-date version of this list is available in [Noreply] **** NOTE: I agree with John that this is a yuckt sort of rule. however, it seems to be common practice. Should we discourage it? Don't know, many loops have been avoided this way..... Should we just document it as a not recommended possibility? **** AV2.2 DISCUSSION: In the Internet, non-delievry messages are recognised by the fact that teh MAIL FROM: has an empty address. RULE: #RFC# Repliers generate an exception output message if the input message has an empty MAIL FROM: address. AV3 RULE: The following attribute of the output message has the value: #84#P2# inReplyTo : IPMessageID of input message #88#P2# replied-to-IPM : this-IPM of input message #822# In-Reply-To: : Message-ID of input message Houttuin Expires March 1994 [Page 14] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 AV4 RULE: The following attributes are optional in an output message. If used, they contain the value: #84#P2# crossReferences : IPMessageID of input message #88#P2# related-IPMs : this-IPM of input message #822# References: : Message-ID of input message AV5 RULE: #P2# The P1.originator of the output message contains the address of the MBS administrator. DISCUSSION: Note that this affects a P1 attribute, but only when the output message is P2. For instance, consider a P1 distribution list that distributes another content type than P2, say Pc. Since Pc may be completely unstructured, changing the P1.originator would make it impossible to reply to the originator of the input message. Changing the P1.originator will also make sense for content types that have P2 like header fields, e.g. for P35 messages. RULE: #821# The MAIL FROM: line of the output message contains the address of the MBS administrator. AV6 RULE: #P2# The P2.originator of the output message contains the address of the MBS administrator. RULE: #822# The From: field of the output message contains the address of the MBS administrator. AV7 RULE: #84#P1#P3# Every PerRececipientFlag in the output message has the following bits set: Report Request: 01 User Report Request: 00 i.e. the Non-delivery Notification service will be prevented. AV8 RULE: The following argument is empty in the output message: #84#P2# Recipient.reportRequest #88#P2# NotificationRequests Houttuin Expires March 1994 [Page 15] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 AV9 RULE: The following attribute of the output message has as value the string 'Re: ', concatenated with the subject of the input message. #822# Subject: #P2# subject AV10 RULE: The following attribute of the output message has as value the subject of the input message, concatenated with the string '(for)'. #822# Subject: #P2# subject AV11 RULE: #P1#P3# The P1.recipient of a (non-)DM equals the P1.originator of the input message. RULE: #821# The RCPT TO: field of a (non-)DM equals the MAIL FROM: of the input message. AV12 RULE: #P2# The P2.recipient of a (non-)DM equals the P1.originator of the input message. RULE: #822# The To: field of a (non-)DM equals the originator of the input message. AV13 RULE: #P1# All P1.ExtensionIdentifiers in an output message are distinct. AV14 RULE: #P2# The output message(s) have the P2.autoForwarded flag set to true. 7.3. Attribute/header conservation (AC) DISCUSSION: Thre are a number of attributes, set by the originator of the input message, that should also be set in the output message. For instance, a user will expect a high priority request to be handled with high priority. The output message should in this case also be sent with the same priority. Note that an MBS may, as a local decission, choose to spool all requests in order to spread the MBS load. As long as the local processing of high priority request can be Houttuin Expires March 1994 [Page 16] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 guaranteed to be no slower than that of normal requests, and the following rules for the output messages are followed, these local processing delays will be transparent for the MBS users. RULE: The following attributes have the same value in the output message as in the input message AC1 In order to propagate the originator's request for privacy to the output message(s): #822# Sensitivity: #P2# P2.sensitivity AC2 #822# Importance: #P2# Importance AC3 #822# Priority: #P1#P3# Priority AC4 #84#P1#P3# ContentType AC5 #P1#P3# contents 7.4. Addresses (AD) Please note that all recommendations for names of MBSs and MBS administrators concern internationally used MBSs. Local MBSs can use similar mechanisms in their local language. AD1 RULE: The address of the MBS administrator is the same as that of the MBS, except for the #RFC# localpart #400# Personal Name Houttuin Expires March 1994 [Page 17] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 AD2 RULE: The MBS administrator of a mailer demon has an address with the following local address designation: #RFC# localpart=postmaster AD3 RULE: The following attribute of the echo server address has the value "echo". #RFC# localpart #400# Surname AD4 RULE: The following attribute in the address of the administrator of a dedicated replier is that of the replier, concatenated with "-reply". #RFC# localpart #400# Surname AD5 RULE: A message addressed to an address with the following local address designation results in an NRN or a non-DM being generated. #RFC# localpart = nosuchuser #84# Surname=nosuchuser #88# Surname=nosuchuser #88# CN=nosuchuser AD6 RULE: The following attribute in the address of the administrator of a dedicated replier is that of the replier, concatenated with "-request". #RFC# localpart #400# Surname 7.5. Body (B) B1 RULE: The input message (all headers and an optionally truncated part of the body) is included in the output message in an end user readable format, preferably as a MIME message body-part, an IPMS.ForwardedIPMessage bodypart, or in plain ASCII text. Houttuin Expires March 1994 [Page 18] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 B2 RULE: Additional information is included in separate bodyparts of the output message. B3 RULE: Commands are only specified in the body of the input message. Especially, a command server ignores the Subject field of the input message. B4 RULE: The recipient of the output message can be uniquely identified from the heading of the input message. That is, alternate recipients are not negotiated in the body of the input message. This ensures that the recipients can still be uniquely identified after the input message has traversed a protocol gateway. B5 RULE: The output message body consists only of the complete input message, encoded as a MIME message bodypart or an IPMS.ForwardedIPMessage bodypart. 7.6. Exceptions (E) E1 RULE: In case of an MBS Submit Permission violation #822#P2# a non delivery message is sent to the originator of the input message. The non delivery message has the following text in the message body: "Originator not allowed to send to this address" #84#P1# a P1.DeliveryReportMPDU will be sent to the P1.originator of the input message. The P1.DeliveryReportMPDU will have the following values: ReasonCode: unableToTransfer(1) DiagnosticCode:uaUnavailable(4) SupplementaryInformation: "Originator not allowed to send to this address" E2 RULE: Only the types of input messages listed below are valid as input messages. Any other type of input message (reports, receipt Houttuin Expires March 1994 [Page 19] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 notifications) leads to the generation of an exception output message. #84#P1# UserMPDU #84#P2# IM-UAPDU #88#P1# Message #88#P2# IPM #822# No restrictions #400# P1.Probes are expected to be handled by the MTS and are thus not interpreted by the MBS. 7.7. Logging (L) L1 RULE: The MBS logs the originator of the input message and all recipient(s) of the output/exception message(s). DISCUSSION: This allows the MBS administrator to track down malicious behaviour. L2 RULE: The MBS logs the message ID of every input message and every output message. It generates an exception message if the same message ID is encountered in the input message more than once. DISCUSSION: This will prevent all routing and MTS-redirection loops amongst MBSs. UA level MBSs, which create a new output message for each input message, will at least be safeguarded against mail storms from other MTS based MBSs. ORIGIN: This document. Similar techniques are already being used in Netnews. AFFECTED: All MBSs. Any further logging is optional. 7.8. Implementation options (I) I1 RULE: MBS Submit Permission implementation is 'implicit'. This means that MBSs that have not explicitly implemented this function can still claim to be implicitly open to anyone. Houttuin Expires March 1994 [Page 20] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 I2 RULE: Auto-repliers at least log the originator of the input message. During the lifetime of an auto-replier, at most one output message per input message originator is generated. I3 RULE: #P2# Even if a DL is used for distribution of P2 messages, we still recommend to implement it at MTS level. This has some important advantages over P3/P2 based implementations (see also [SHK 92]): - Using P3 would result in loosing P1.TraceInformation - Better alignment with X.400(88), which also defines DLs within the MTS - An MTS DL distributes P1.UMPDUContent transparently, and will thus implicitly implement one of the requirements for DLs. 8. Summary table auto- comm. mail. echo auto- dist. affected answ. serv. demon serv. forw. list AR1.1 + + + + . . P2 AR1.2 + + + + . . 822 P2 AR1.3 + + + + . . 822 P2 AR1.4 + + + + . . 88.P1 88.P3 AR1.5 + d + d d . 822 P2 AR2 + + + + + . all AR3 o + - + n/a n/a 822 P2 AR4 o + - + n/a n/a 822 P2 AR5 o + . + n/a n/a 822 P2 AV1 o + - + . . 822 P2 AV2 s + + + . . all AV3 + + + + n/a n/a 822 P2 AV4 + + + + n/a n/a 822 P2 AV5 o + + + . . 821 P1 P3 AV6 o + + + . . 822 P2 AV7 + + + + . . P1 P3 AV8 + + + + . . P2 AV9 s s o + - - 822 P2 AV10 - - - - s - 822 P2 AV11 . . + . n/a n/a 821 P1 P3 AV12 . . + . n/a n/a 822 P2 AV13 + + + + + + P1 AV14 - - - - + - 822 P2 AC1 + + + + + + 822 P2 AC2 + + + + + + 822 P2 AC3 + + + + + + 822 P1 P3 AC4 . . . s + + P1 P3 Houttuin Expires March 1994 [Page 21] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 AC5 - - - - - + P1 P3 AD1 + + + + + + all AD2 o - + - o - all AD3 n/a n/a n/a + n/a n/a all AD4 n/a s n/a s n/a n/a all AD5 n/a n/a + n/a n/a n/a all AD6 n/a n/a n/a n/a n/a s all B1 - o s + - - 822 P2 B2 o o o o - o 822 P2 B3 n/a + n/a n/a n/a n/a 822 P2 B4 n/a + n/a n/a n/a n/a 822 P2 B5 - - - - + - 822 P2 E1 + + + + + + 822 P2 E2 + + + + + + all L1 o + + + o o all L2 + + + + + + all I1 n/a s n/a s n/a s all I2 s n/a n/a n/a n/a n/a all I3 n/a n/a n/a n/a n/a s n/a Table 1. Table of recommendations Key to symbols in table 1: + Recommended s Suggested o Optional d Don't care n/a Not applicable . Depends on other factors - Not recommended 8. Reference implementations There are a number of MBS implementations that follow most of the recommendations listed in this document. They include: Echoput (echo server) Concord (echo server, DLs) AUSSIE (echo server) Squirrel (command server) EAN (DLs, auto-forwarding, auto-answer, echo) PP (DLs, auto-answer, echo) Developers of other MBS software (mailbase, explode) have indicated they will also implement the requirements in future versions. Houttuin Expires March 1994 [Page 22] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 9. Further work An idea would be to write a modular MBS system, which can be cofigured as an echo server, distribution list, etc. A protocol conversion module can be used to allow the MBS to plug in to different implemenations and protocols. 10. Acknowledgements Within the context of the connectivity testing tool 'concord', initial work on the requirements for echo servers and distribution lists was done within COSINE MHS and XNREN ([Concord], [Concreqs]). The document was then integrated in the work of the IETF Mail Applicability Design Team, consisting of: Ned Freed (INNOsoft), Jeroen Houttuin (RARE), John Klensin (INfoods, UN), Keith Moore (University of Tennessee). Thanks for ideas, comments, flames and corrections: Harald Alvestrand (SINTEF), Allan Cargille (XNREN), Urs Eppenberger (SWITCH), Paul Klarenberg (NetConsult AG), Ignacio Martinez (redIRIS), Juan Pizzorno (DFN), Eric Thomas (SUNET), Johan Vromans (Multihouse), Jan van der Weele (Du Pont). 11. Bibliography 821 Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821, University of Southern California, Sept. 1982 822 Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, UDEL, Sept. 1982. 1123 R. Braden, Editor, "Requirements for Internet Hosts - - Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989. 1211 Westine, A. & Postel, J., "Problems with the Maintenance of Large Mailing Lists", RFC 1211, March 1991. 1327 Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, UCL, May 1992. 1328 Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328, UCL, May 1992 Houttuin Expires March 1994 [Page 23] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 1341 N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions), RFC 1341, June 1992 Concord J. Houttuin, "Concord functional specification", COSINE MHS server, Mail: cosine-mhs- server@nic.switch.ch, FTP: nic.switch.ch, Username: cosine , File: tools/operational/concord/xxxxxxxx Concreqs J. Houttuin, Allan Cargille, "Requirements for concord echo servers and distribution lists", COSINE MHS server, Mail: cosine-mhs-server@nic.switch.ch, FTP: nic.switch.ch, Username: cosine, File: procedures/echo-server-reqs Noreply "list of surnames/usernames not to automatically reply to", RARE server, Mail: server@rare.nl, FTP: ftp.rare.nl, File: working-groups/wg-msg/div/dontreply X.4xx(84) CCITT Recommendations X.400 - X.430. Data Communication Networks: Message Handling Systems. CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga- Torremolinos 1984 X.4xx(88) CCITT Recommendations X.400 - X.420. Data Communication Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne 1988 SK92 Kille, S., "MHS use of the Directory to support distribution lists", Internet-Draft draft-ietf-mhsds- mhsuse-02.txt, November 1992 12. Abbreviations ASCII American Standard Code for Information Exchange CCITT Comite Consultatif International de Telegraphique et Telephonique COSINE Co-operation for OSI networking in Europe DL Distribution List DM Delivery Message EAN MHS software (not an abbreviation) IPM Inter-Personal Message IPN Inter-Personal Notification ISO International Organisation for Standardisation MHS Message Handling System MBS Mail based server MOTIS Message-Oriented Text Interchange Systems MTA Message Transfer Agent MTL Message Transfer Layer MTS Message Transfer System Houttuin Expires March 1994 [Page 24] INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993 NJE Network Job Entry NRN Non-Receipt Notification PP MHS software (not an abbreviation) RARE Reseaux Associes pour la Recherche Europeenne RN Receipt Notification SMTP simple mail transfer protocol UA User Agent 13. Author's Address Jeroen Houttuin RARE Secretariat Singel 466-468 NL-1017 AW Amsterdam Europe Tel +31 20 6391131 Fax +31 20 6393289 houttuin@rare.nl /S=houttuin/O=rare/PRMD=surf/ADMD=400net/C=nl/ Houttuin Expires March 1994 [Page 25]